A DNS root zone is the top-level DNS zone in a hierarchical namespace using the Domain Name System (DNS). Most commonly it refers to the root zone of the largest global network, the Internet.
The US Department of Commerce NTIA exercises the ultimate authority over the DNS root zone of the Internet.[1] The zone is managed by the Internet Assigned Numbers Authority (IANA) as the operator while a third party is contracted by the NTIA as the root zone maintainer. The IANA operator is ICANN and the root zone maintainer is Verisign, Inc.
A combination of limits in the DNS definition and in certain protocols, namely the practical size of unfragmented User Datagram Protocol (UDP) packets, resulted in a limited number of root server addresses that can be accommodated in DNS name query responses. This limit has determined the number of name server installations at (currently) 13 clusters, serving the needs of the entire public Internet worldwide.
Contents |
There are thirteen root server clusters that are authoritative for queries to the global DNS root zone. The root servers hold the lists of names and addresses for the authoritative servers for all top-level domains. Every name lookup must either start with a query to a root server or use information that was once obtained from a root server.
The root servers have the official names a.root-servers.net to m.root-servers.net. However, to look up the IP address of a root server from these names, a DNS resolver must first be able to look up a root server to find the address of an authoritative server for the .net DNS zone. Clearly this creates a circular dependency, so the address of at least one root server must be known by a host in order to bootstrap access to the DNS. This is usually done by shipping the addresses of all known DNS root servers as a file with the computer operating system: the IP addresses of some root servers will change over the years, but only one correct address is needed for the resolver to obtain the current list of name servers. This file is called named.cache in the BIND nameserver reference implementation and a current version is officially distributed by ICANN's InterNIC.[2]
Once the address of a single functioning root server is known, all other DNS information can be discovered recursively, and the address of any domain name may be found.
The root DNS servers are essential to the function of the Internet, as most Internet services, such as the World-Wide Web and electronic mail, are based on domain names. The DNS servers are potential points of failure for the entire Internet. For this reason, there are multiple root servers worldwide. The number has been limited to 13 in DNS responses because DNS was limited to 512-byte packets until protocol extensions (EDNS) were designed to lift this restriction. While it is possible to fit more entries into a packet of this size when using "label compression", 13 was chosen as a reliable limit. Since the introduction of IPv6, the next-generation Internet Protocol, previous practices are being modified and extra space is filled with IPv6 name servers.
The root name servers are hosted in multiple secure sites with high-bandwidth access to accommodate the traffic load. At first, all of these installations were located in the United States. However, the distribution has shifted and this is no longer the case. Usually each DNS server installation at a given site is physically a cluster of machines with load-balancing routers. A comprehensive list of servers, their locations, and properties is available at http://root-servers.org. As of May 2011 there were 242 root servers worldwide.
The modern trend is to use anycast addressing and routing to provide resilience and load balancing across a wide geographic area. For example, the j.root-servers.net root server, maintained by VeriSign, is represented by 41 (as of July 2008[update]) individual server systems located around the world, which can be queried using anycast addressing.
IANA is responsible for receiving requests to edit root zone file data from the various TLD operators and approving and submitting them. Under the current arrangement, after approving the change request from a registry, IANA sends the request to the NTIA for approval, and if approved it is sent to the root zone maintainer for physical implementation to the root zone file. While the NTIA has over the years ceded control of the administrative and policy-making aspects of the Internet DNS to ICANN such as setting policy, approving new TLDs, certifying registrars, and awarding registry contracts for existing TLDs, the technical management functions continue to be held by the US Government and executed through the IANA functions contract. While ICANN is also the IANA functions operator, in theory the US Government could select a different organization upon expiration of the current contract and many people feel that it would make it very difficult for ICANN to manage the internet's DNS without the IANA contract. While there has been much international pressure for the US Government to completely transfer the IANA functions over to ICANN in the same way it did the general administration of the Domain Name System, the US Government has maintained that it will maintain its historic role in overseeing the IANA functions and has no plans to transfer this authority over to ICANN. A major reason that the NTIA has given for continuing the contract format is that it feels it is best to keep the administrative aspects and political bureaucracy of managing the DNS sepearate from the technical management, and as part of the contract ICANN has to keep its staff that are in charge of managing the IANA functions completely separate from those involved in the policy making side to the company. ICANN even does this physically as they are currently headquartered in two office suites, one for ICANN itself and the other for the IANA related staff. Many of the same critics of the US Government's role wish to remove VeriSign's role as the direct root zone maintainer and allow IANA to directly maintain it as some believe that the US Government has kept VeriSign in this role to solidify US control over the root zone.
The establishment of DNSSEC in the root zone again brought these issues to the table and both ICANN and VeriSign put forward competing proposals for the installation of DNSSEC in the root zone. ICANN (as the IANA operator) wished to generate both the Key Signing Key and Zone Signing Key architecture and through its proposal it also wished to take control of the actual editing of the root zone and alter the current editing process. Under their plan, they would both edit and sign the zone after NTIA approval. VeriSign's role would have been reduced to simply receiving and then distributing the signed zone file to the 13 servers through its existing distribution system. VeriSign's proposal argued for keeping the current editing arrangement in place of ICANN submitting, NTIA approving, and VeriSign editing. VeriSign proposed that VeriSign should generate the ZSK and that the KSK should be generated in a key ceremony of the 13 root server operators. A quorum of the server operators would have to be present for key generation to take place. The NTIA ultimately released the final plan which closely resembled VeriSign's proposal, but as a compromise gave ICANN control over the KSK while giving VeriSign control over the ZSK.